Software installation files are known in the art. Such files are used to install and/or setup software applications for use by an end user. Installation files are typically “self-extractors.” A self-extracting file is an executable file comprising one or more compressed files and the instructions required to extract and setup the compressed file(s) as an executable software application.
FIG. 1A illustrates an example of a typical self extracting installation file 1. Installation file 1 comprises a setup program 2 and possibly compressed program files 5. Compressed program files 5 comprise a number of individual files required to run a software application. Setup program 2 comprises the logic required to set up these files for use.
When installation file 1 is executed, setup program 2 is extracted as setup program 2′. Setup program 2′ is then launched to continue the installation and set up of the software application. It extracts each of compressed program files as program files 5′ and typically interacts with the operating system to provide the end user with means to run the newly installed application. Examples of typical program files include: executable files (EXE), dynamic link libraries (DLLs), database files (DBF) and help files (HLP).
There are also non self-extracting installation files. These installation files typically have instructions on where to find the files to install; for example, on a CD or at a URL.
There are also one-level installations. In such installations, the functionality of setup program 2′ is included in installation file 1; there is no need to extract a separate executable program to continue and complete the installation process.
Installation files are sometimes personalized or customized with information pertaining to a specific end user. For example, data such as the user's name and/or account information may be included along with the software application. Such personalization is typically accomplished by entering the relevant data at the time of purchase and compiling a personal installation file for the specific user.
FIG. 1B illustrates an example of a typical personalized installation file 1. Similar to FIG. 1A, installation file 1 comprises a setup program 2 and compressed program files 5 which are then extracted as setup program 2′ and program files 5′. However, installation file 1 may also comprise personalization data 3. After personalization data 3 is extracted as personalization data 3′, setup program 2 uses this data to personalize some or all of program files 5′ for a particular user and/or installation.
Some operating systems, such as recent versions of the Symbian operating system for mobile devices, require an application to be “signed” in order to allow it to run and/or access certain system functionality. Signed applications are typically tested for stability and functional accuracy in order to ensure that they conform to expected standards of behavior for a given environment.
A signed application includes a “digital signature” that is used by the operating system to authorize the use of system resources by an application. Such digital signatures typically include logic to check whether or not the application's installation package and contents have been modified subsequent to the signing process. Accordingly, if an application or any of its included files have been modified, it will typically require retesting and re-signing before it can be distributed and used.
The testing/re-signing process typically requires a non-trivial investment of time and resources. Signed installation files are therefore usually not personalized by compilation.